23 结束语¶
读到这里,相信你已经将本课程全部学完,对 Spring Cloud、Spring Cloud Alibaba 两个开源项目整体上有一个更加直观的认知,经过本次实际操作,是不是也没有想像中的那么难,一旦你将整个开发全貌有体系的接触之后,微服务思想也可以渗透到日常的开发工作中去。本篇,就带你做个简单复盘,回顾下整个课程体系。
前景回顾¶
本次实战选用的是常见的商场停车场景,旨在通过简单的场景融入微服务开发技术体系,逐步完善迭代,达到我们学习并实践微服务技术开发的目标,内容还是主要聚集于技术开发,系统运维层面涉及的内容较少,随着 DevOps 的流行,相信越来越多的公司开发与运维的边界逐渐消失,彻底融合在一起。
提到微服务,必然涉及到服务的拆分,拆分粒度究竟多细,业内没有统一的标准,依团队能力而异。太粗了,达不到效果,太细了管理起来繁杂冗余。服务拆分后,底层存储也涉及到拆分问题。即便是没采用微服务,在业务增长快速的情况下,分库分表也是比较常见的情况,这里涉及到垂直拆分以及水平拆分的问题。
垂直拆分,根据表功能不同,以近似属性划分,拆分为不同的小数据库。当库中单个表的容量超大时,就需要按不同纬度进行水平拆分,分布在形如 A_01、A_02、A_03……等不同的表中。本案例中不涉及水平拆分问题,如果存储体系不变,终究是遇到水平拆分的问题。
技术点回顾¶
技术是为业务服务,技术栈只有在适当的业务场景中才能发挥出应用有作用,这里列一个表格,将业务场景与技术应用对应起来。
使用业务场景 | 技术点 |
---|---|
商场用户绑定手机号、开通月卡 | 服务间调用,RestTemplate、Feign、Ribbon |
各个子服务对外的在线 API 管理 | Spring Boot 与 Swagger 集成 |
商场停车收费系统对外聚合 API | Spring Cloud Gateway 与 Swagger 整合 |
子服务模块众多时,如何管理这些服务接口 | 通过 Nacos 进行服务管理 |
特殊节日下,绑定手机号赠送积分与往日不同 | 使用 Nacos 做分布式配置,供所有服务调用 |
停车场可用车位数展现,停车计费规则 | 分布式缓存 Redis |
定时向会员推送营销短信 | 分布式定时任务,整合 Shedlock |
商场优惠券兑换 | 分布式锁应用 Redis 整合 Redission |
面向不同终端的数据装配 | BFF 架构应用 |
优惠券兑换洗车 | 与 RPC 框架 Apache Dubbo 整合 |
屏蔽内部接口,对外统一的路由控制 | Spring Cloud Gateway |
服务调用时,响应慢或服务不可用时,需要快速失败 | 整合 Hystrix |
网关进行限流限制,防止流量过大 | Sentinel 设定特定规则 |
网关鉴权,安全防护 | Spring Cloud Gateway 整合 JWT |
付费出场时,计费数据的完整性 | 使用分布式事务,整合组件 Seata |
每个子服务的健康状态如何 | 整合 Spring Boot Admin |
确定服务间调用时请求的完整链路 | Apache SkyWalking |
实践出真知,通过简短 20 几节内容,各个环节是没有办法进行深入的讲解,所以就需要大家在实际应用过中,边摸索边学习,稳扎稳打。
微服务是万能的吗?¶
近两年,微服务的一度火热,似乎成了拯救自家业务的银弹。用微服务不等于就解决了一切问题,它与公司的组织架构、技术储备、业务走向、技术投入等都有很大的关系,需要产品、开发、测试、运维等各岗位人员通力配合。在没有一个开放性的、敏捷的思维框架下,不管是初次实施微服务开发,还是基于原有业务进行微服务架构重构,都面临着很大的挑战,同时它对系统测试运维有了更高的要求,不是说开发完就结束了。在软件生命周期过程中,开发仅占了很小的一部分,大部分阶段是处于运维阶段。
有必要开展微服务架构吗?业务发展快速,技术起点高且团队应用成熟的情况下,可以直接从微服务架构起步。或者系统已经复杂,维护难度越来越大,时间允许的情况下,进行微服务架构重构也是可能的,但也不可直接推倒重来,只能采用绞杀模式,一步一步替代,否则上来直接重写,代价是相当高的。
不要瞧不上单体应用,深度挖掘潜力后,完全可以应付正常的业务使用,一般情况下,还是建议从单体应用开发起步,业务稳定后,再做进一步打算。适当的设计,才不会造成成本浪费。
微服务不仅仅是开发¶
微服务不仅仅是开发,还有后期长期的运维与升级。本篇仅讲述了开发部分,后期生产系统的部署运维,还有很长的路要走。DevOps 时代要求开发有更多的运维技能,甚至在开发阶段就已经进入运维角色。容器化部署、自动化扩容、弹性扩展等等,微服务架构的过程还有很长的路要走,希望小伙伴们继续保持学习的劲头,再接再励。